The present invention involves the field of telecommunications and, in particular, the invention relates to methods and apparatus for managing Voice Over Internet (VOIP) calls, for example terminating in a Public Switching Telephone Network (PSTN).
Numerous advances have been made in the field of telecommunications. In particular, the field of Internet telephony has emerged as a viable technology that is evolving at an ever increasing rate. Evidence of this evolution of Internet telephony is best characterized by the number of products that have become available in the market. Products such as CoolTalk by Netscape Communications Corporation of Mountain View, Calif.; Internet Connection Phone by International Business Machines of Amonk, N.Y.; Intel Internet Phone (IPhone) by Intel Corporation of Santa Clara, Calif.; NetMeeting by Microsoft Corporation, Redmond, Wash.; Quarterdeck WebTalk by Quarterdeck Corporation of Marina Del Rey, Calif.; TeleVox by Voxware Incorporated of Princeton, N.J.; and WebPhone by Netspeak Corporation of Boca Raton, Fla., are representative of the current state of applications facilitating Internet telephony.
Each of these products offers Internet based voice communications with a telephone motif, between two users each using the same (or compatible) product on either end of the Internet connection. That is, the Internet provides the “switching” architecture for the system, while the computer acts as the “handset”, or the audio interface. One reason for the proliferation of these applications is a desire to push the technology of the Internet to provide a total communications tool. The appeal to users is that the use of the Internet is free of toll charges. Therefore, a user of an Internet phone product may communicate with another user located anywhere else in the world without having to pay the long distance charges associated with making a telephone call using the PSTN.
It is noted that a VOIP call need not involve the use of client terminals (user computers) at each end thereof as is the case with the above products. Indeed, any type of telephone terminal, handset, cell phone, etc. may be used to initiate or receive a VOIP call by connecting to a PSTN and thereafter traveling through the Internet over one or more gateways.
The PSTN is a circuit switched network. That is to say that the PSTN assigns a dedicated communication line to a user with which to complete the telephone call, wherein the user can utilize the assigned resource of the PSTN in any way they choose. It is understood that the user is paying for the use of the dedicated resource of the PSTN. While the circuit switched approach of the PSTN system is not necessarily the most efficient system in terms of call traffic (i.e., it does not make use of the “dead space” common in a conversation), it is relatively easy to ensure that information destined for a particular user is delivered. The PSTN provides a dedicated line to complete the transaction.
The Internet is a packet switched network, where communication is accomplished by breaking the transmitted data into varying-sized packages (or “packets”), based primarily on communication content, and interleaving the packets to best utilize the bandwidth available at any given time on the Internet. When the packets reach their intended destination, they must be reassembled into the originally transmitted data. Loss of packets, and thus data, occur frequently in such a network, and the ability of the network to successfully transmit information from one point in the network to another determines the quality of the network. For inter-computer communication transactions involving non real-time data, the ability to transmit packets and retransmit any packets that are perceived to have been dropped is not a severe limitation and may not even be perceived by the user of the system. However, in a voice communication transaction, the delay required to retransmit even one data packet may be perceived by a user.
A system of gateways disposed on the Internet facilitates VOIP telephony by permitting the gateways to act as protocol bridges between the PSTN and the Internet. For example, ITXC Corporation of Princeton, N.J. operates a global VOIP network, called ITXC.net®, which can facilitate a VOIP call that traverses both PSTN networks and packet switched networks like the Internet. The originator of a VOIP call may use a standard telephone connected to a first PSTN to dial a telephone number of another person on a different PSTN. A number of trunk lines of the first PSTN connect to a plurality of gateways (servers) that connect the first PSTN to a packet switched network, such as the Internet. One of the gateway servers (say an initiator gateway) will handle the initiated call from the first PSTN. In particular, the initiator gateway will send its position in the network along with the telephone number of the other person (within the second PSTN) to a rate engine/directory gatekeeper. The rate engine/directory gatekeeper determines which of many other gateways should be used to complete the call to the telephone number in the second PSTN (say a terminator gateway) and transmits this information to the initiator gateway. The rate engine/directory gatekeeper also keeps accounting information in accordance with well-known clearinghouse billing models. The initiator gateway then establishes a call connection with the terminator gateway (which may involve routing the call through a number of intermediate servers on the Internet). The terminator gateway completes the call to the other person by connecting to the second PSTN over one of the trunk lines thereof.
Further details of certain portions of the ITXC.net® global network and other associated elements and systems may be found in U.S. Pat. Nos. 6,628,760; 6,404,864; 6,310,941; 6,304,637; 6,298,056; and 6,212,192, the entire disclosures of which are hereby incorporated by reference.
Although advancements are being made in the technologies associated with VOIP telephony, both users and service providers are generally satisfied with the current state of the art in so far as quality of service and billing are concerned. This is not to say, however, that problems do not occur. For example, from time to time the terminator gateway may act as if the VOIP call is active despite the fact that the call is actually inactive and that the initiator gateway recognizes that the call has ended. This can create a significant problem in connection with billing, in as much as a substantial discrepancy can exist between the number of call minutes that the initiator gateway records as compared with the number of calling minutes that the terminator gateway records. These calls are referred to as “hung calls” or “long calls” in the art and the discrepancies that result may be measured in minutes, hours, and even days. Hung calls result in significant loss of revenues either because the discrepancy may not be resolved or because significant resources in terms of personnel and lost opportunities may be required to resolve any such discrepancies.
An existing technique for mitigating the discrepancies associated with hung calls involves the use of so-called RTCP timers, which measure the flow of RTCP packets that are transmitted and received in connection with the call. Each of the gateways in the system employ the RTCP timers to determine whether sufficient data packets are flowing as a measure of whether the call is active or inactive. For example, if in a given call no RTCP packets flow within a 55 second time period, then the gateway takes steps to tear down the call. Although the use of RTCP timers are helpful in combating hung calls and the billing discrepancies associated therewith, they are not effective 100% of the time. Indeed, substantial data packet latency and/or packet loss may affect the ability of the RTCP timers to detect a hung call, thereby permitting the hung call to remain and the discrepancy to occur.
A conventional technique to address a hung call that is not detected by the RTCP timers involves the use of a tool command language script that is stored within each of the gateways in the system. On a periodic basis, the script is executed in order to determine whether any calls have an up-time over a predetermined threshold, such as 180 minutes. Thus, the script technique ensures that no discrepancy can exceed 180 minutes.
Unfortunately, the use of scripts that reside at the respective gateways of the system are problematic for several reasons. First, a service provider must have access to each of the gateways in order to load the script and ensure that it operates properly. Second, once the script is loaded into a given gateway, the predetermined threshold (e.g., 180 minutes) is fixed and cannot be altered without a significant retrofit activity in which new scripts are loaded into each of the gateways of the system. It is noted that the aforementioned problems are exacerbated when the gateways are not owned by the service provider seeking to minimize the number and extent of hung calls. Indeed, any number of third party entities may own the gateways, thereby presenting a significant obstacle in terms of implementing a script routine. Finally, the invocation and execution of a script at the gateways of the system represents a significant overhead activity that reduces transmission efficiency and data throughput.
Accordingly, there are needs in the art for new methods and apparatus of managing VOIP calls, particularly with respect to minimizing the occurrences and extent of hung calls.